Simple or Easy
#設計 #設計原則 #プログラミング
シンプルさの必要性
技術の螺旋を見抜くときに重要な概念
長生きしている技術は一貫してSimpleである
SimpleとEasyは違う / Simple is not Easy
Easyは
糖衣構文の成分が強い
jQueryとか、ユーティリティ(lodash)とか
Simpleは
既知の課題を抽象化する
自然と課題へ正しくメンタルモデルで向き合えるようにしてくれる
React Fiberとか
Easyさを売りにしたフレームワークやライブラリに頼る = 「意思疎通することに通訳を通している」自覚が必要
パフォーマンスが落ちることや暗黙挙動にハマることを考慮しておかねばならない
生殺与奪の権を他人に握らせるな
不確実性や複雑性は隠蔽するのではなく向き合い方を知るべし
フレームワークは思考を癒着させる
可読性、理解容易性、正しさへの迷いは作業者のバックグラウンドに依存する
DSLや独自テンプレート構文系は短期的には流行っても、長期的に廃れることが多い
Dan AbramovもReduxの黎明期のDSLエコシステムが乱立した時代にこのことへ言及していた
https://github.com/pitzcarraldo/reduxible/issues/8#issuecomment-168312463
As soon as you have such helper used in a codebase new people start to structure their code in similar ways because they think that's how it should be done.
The point of Flux and Redux is to make it easy to suddenly start reacting to the same action in a different place. You don't know which actions you'll need to handle in different places in advance.
One needs to look at the code not just from "how it looks now" perspective but also "how will it evolve" and "how can we reduce risks when requirements change". This pattern locks you into a very particular way of doing things. When you'll get more requirements you'll have to rewrite the part that used this helper anyway. This is why I consider providing such helper harmful, even if it seems to make code simpler in some cases. Requirements change!
---
このようなヘルパーがコードベースで使われるようになると、新しい人たちが同じような方法でコードを構成し始める。
FluxとReduxのポイントは、同じアクションに違う場所で突然反応し始めることを簡単にすることだ。異なる場所でどのアクションを処理する必要があるかは、事前にわからない。
コードを「今どう見えるか」だけでなく、「どう進化するか」「要件が変わったときのリスクをどう減らすか」という視点で見る必要がある。このパターンでは、非常に特殊なやり方に縛られてしまう。要件が増えたら、どのみちこのヘルパーを使った部分を書き直さなければならない。このようなヘルパーを提供することは、場合によってはコードを単純化するように見えても、有害だと考えるのはこのためだ。要件の変更!
「今どう見えるか」ではなく「どう進化していくか」
要件がデカいとどうリファクタリングしても別に実装が小さくなるわけではない
「今どう見えるか」だけでなく、「どう進化していくか」「要件が変わったときにどうリスクを減らすか」という視点でコードを見る
@shibu_jp: 「EasyよりSimple」と言う言葉は、通っぽい感じだけど、とことん作り込まれてソリッドになったEasyってのは別格の価値があるよな、ってのはNext.jsを見て思うところ。僕も普段はGoとかSimpleよりな選択が好みなんだけどね。Next.jsはいいやつ。
「シンプル」という言葉、もう「自分の推しのアーキテクチャ」くらいの意味しか持っていない